技术人 | 如何做一个明白状况的研发主管？
编者按：作者谷朴是阿里巴巴CTO线的一位技术管理者，本文他更多从组织层面来探讨研发团队TL角色的定位，也很适合在考虑自己职业发展规划的同学参考。内容聚焦在一线的研发主管，对于管理管理者的角色(manager of managers)暂不涉及。
很多同学在科技公司的发展路径都是写代码、晋升、继续写代码，然后下一步呢？如果有机会担任研发团队一线管理者角色，是否需要争取这个转变？这样的转变意味着什么？阿里也在讨论关于P和M的分离，那么，到底一个研发团队的管理者是P还是M呢？如何做个不PUA的研发主管？
术语：
● IC: Individual contributor，个人贡献者，指不担任管理职责的研发。
● M：Manager，指的是团队的管理者，阿里用TL(Team leader）指称，本文尽量用中文全称或者M缩写。
● 技术负责人：缺乏相应的英文缩写，原因是在国外一般是 Tech Lead (TL）来指代技术负责人，但是我们已经用TL来作为管理者缩写了，因此使用中文全称。
负责一个产品（或者产品模块）/系统/子系统的演进（Conway定律，就算这个团队一开始不是负责某个系统/产品，时间长了系统或者产品也会演变成围绕组织边界划分）
因为负责相关的产品/模块/系统，交付业务所需要的需求、功能、部署和维护（可能因为DevOps / SRE模型的不同这部分的分工有差异）。
从研发团队自身的定位，我们很容易看到，一个研发团队为了能够实现自身的职责，需要如下的角色：
技术负责人：项目落实于产品/技术组件/系统，每个产品/系统需要有技术负责人，技术负责人的具体职责，后面会单独讨论。
人员管理：招聘、绩效、人员日常的管理、团队协同、资源。
项目管理者：研发活动经常以项目形式组织，需要团队内外的协同，项目的推进需要项目管理者的参与，因此这是另一个团队所需要的角色。
开发：研发团队的开发同学。
由于我们探讨的是管理者本身，因此“人员管理”的角色职责毫无疑问是在范围内的，那么剩下的就是技术负责人/项目管理，按照不同管理者的职责范围，就有了不同的模型。不过，在探讨不同的角色模型前，我们有必要进一步明确各个角色的职责（项目管理的部分相对来说更为灵活和解耦，本文因为篇幅关系就略过不讨论了）。
技术工作的4层职责模型
先说说什么是技术负责人。技术负责人负责的不是技术么？是也不是。负责技术，但是如果没有一个“实在”的东西负责，其实这个角色就很难发挥作用。这也是今天很多架构师运转不顺畅的原因，大体上都是没有足够的权责统一。
技术负责人要负责系统，负责产品。每一个系统/产品，都需要有明确技术负责人。同时 该系统内部可能还划分几个子系统，可以按照需要设定子系统的技术负责人岗位（当模块/子系统有多于一个工程师参与时）。子系统技术负责人在技术决策上需要服从上层系统技术决策。
技术负责人需要承担系统真正owner的权责，并为结果负责，否则就不是真正的技术负责人。大部分研发团队的管理者本身也兼任团队所负责系统的技术负责人，但是并不是所有的管理者都有意识地做好了这项工作。当然，技术负责人也可以和团队管理者角色分离。今天我们看到不少系统缺乏真正的owner，导致很多技术演进问题长期得不到解决，而架构师又难以落地，可以说都是技术负责人角色不清晰导致问题。
具体来说，如何才算是做好了技术负责人的工作？首先，针对我们通常意义上的技术工作的贡献，可以定义一个如下的层次模型：
（Level 1）写代码（负责具体实现）
（Level 2）review代码，做方案设计（负责方案落地）
（Level 3）review技术方案设计（负责项目/落地）
（Level 4）建议新方向，把关新方向（负责整个领域的演进和结果）
管理者（M）角色的3个选择
最不希望看到的是转到manager是因为对权力的追逐。对Corp ladder的追逐是大公司病的主要问题之一。身处其中的管理者，如果把带不带人、带多少人作为自己追逐的目标，而且将这一条路看做是向上发展的唯一道路，那么我们会很容易看到抢地盘、内耗、因人设岗等诸多弊病。把帮助团队的发展，通过管理支撑团队带来更大的成就作为目标，是我们应该有的出发点。
管理者的重心毫无疑问是“管理”，但是管理者贡献的价值是什么？这涉及到如何看待团队成员问题。公司有数量庞大的管理层，公司付出给这些管理层的成本是为了什么？管理层如果能从带给团队的价值角度看待自己的定位，是真正做好管理者的前提。从通常角度说，对团队的价值要包含：需要保持信息的通畅、需要对齐组织的目标、需要支撑好自己的团队让团队发挥最大的效率。
简单来说，对团队没有帮助的主管不如没有，有贡献的主管一定是清楚自己的团队需要什么帮助的。主管的价值在于带来的增量而不是团队成员的贡献总和（说不定有这个主管，整体产出比大家自己干还下降了呢）。
具体来说，这些增量的贡献包括但是不限于：
带来团队所需要的技术负责人角色：如果团队需要自己做技术负责人，要能够对技术方案决策负责，为技术演进的方向负责。或者，能找人来代理这部分工作，在需要时，能帮助团队解决技术问题，是否能够通过design review, code review将规范、设计思想、好的代码和设计的要求传递给同学？从这一点来看，对于一线研发团队来说，如果可能的情况下尽量安排技术负责人+M兼任的主管会更好。
传递给团队清晰的目标：有时团队会处于复杂的局面下，目标不够清晰，主管这时责无旁贷需要明确团队的目标，并传递给团队成员。
安排清晰合理的团队内分工：团队内的分工也是个技术架构问题，做好内部的分工，让团队成员可以相互信任和依赖，这是主管的核心职责。
带给成员困难时的指导：每个工程师都会在不同阶段遇到困难，即使资深工程师也会遇到自己难以解决的问题，识别并帮助他们走出这些困难，是主管作为教练角色需要承担的职责。
团队和其他团队边界有冲突时：明确边界，解决冲突，是主管应该为团队贡献的工作。
帮助团队解除阻塞：协助团队解决问题或者上升解决阻塞。
简单来说，这个增量价值就是要解决一些团队成员不能解决的问题，让目标更清晰，协作更顺畅，这一切都是围绕着“让团队的成员更好地发挥、更好地产出”为目标服务的。
管理团队目的是要交付结果，需要更好地激励团队的成员。如何构建这样的氛围呢？
建设一个能拿结果，有战斗力的团队，团队成员一定是非常有动力地在工作的。如何能够达到这个状态？有很多领导力的书籍讲这个问题，这里无意重复。但是我觉得，首先要强调是在团队的成员和主管之间构建信任。信任的构建是双向的，在高效的组织中，如果缺乏了任何一个方向的信任，都将带来效率的下滑。
赢得团队的信任：作为主管，要能够诚实沟通、有良好的动机（客户第一、帮助员工成长等而非抢夺地盘甚至搞内部政治）、公平对待成员。我至今仍然清楚记得自己刚开始担任主管前，我当时的主管和我的谈话，他告诉我，信任是相信对方“have their best interest in mind”（相信对方考虑自己的核心利益）。这句话我也一直铭记在心。在今天的权力结构体系下，这种信任来自于主管真诚的关注成员的发展而不只是自己阶段性的目标。事实上，做到了这一点的团队，只会更有战斗力，能够达成更好的结果。 相信团队成员：主管相信员工，需要做到的是：清晰地沟通目标，相信员工的目的和动机是自我实现和带来影响力，提供清晰的组织边界和团队内的结构从而让组织成员可以相互依赖而不是相互竞争。Google内部180个团队的研究清晰揭示了这些组织因素对于团队效率的影响，而其中最重要的是心理安全（在团队中能够安全的进取并承担风险），这需要主管能够给予员工足够的支撑，从而最大化释放出成员的意愿。组织也因此需要Blameless的文化，尤其在涉及到故障、事情进展不如人意的时候，深入根因，blame-aware但是对复杂的问题不以简单粗暴惩戒来解决。
同时，作为背景知识，我们每个人都应当了解工程师是如何被激励的。推荐所有主管以及希望成为主管的同学仔细看一下RSA what motivates us视频，研发主管需要理解研发活动的本质驱动力：即自主性（Autonomous）、精通（Mastery）和目标（Purpose）。
理解研发活动的本质驱动力，我们可以更好地反思自己的角色定位，更多成为一个视人为人的主管，能够赋能团队，能够让同学能够有驱动力并感受到自身的成长，从而带领团队获得更好的结果。
了解和团队成员的5种互动模式
重要的是，在每一个谈话、会议和讨论之前，我们需要想清楚一个问题：今天应该用什么模式？这个同学，我是应该以指导为主、支持为主还是可以授权给他？要有意识地问清楚自己这些问题：
指导和教练coaching：适用于两种场景，一种是对于团队的新人、比较初级的工程师，需要采用教练的模式，主管应该花更多的时间，针对具体的案例帮助同学分析、明确目标、明确路径，教会同学未来遇到同样问题时的解决方案。具体可以参考GROW模型[1]；第二种是团队成员寻求帮助，这时是coaching的好机会，可以不必急于给出答案，而是帮助同学掌握解决问题的方法。
支持Support：支持和coaching不同，但可能是管理者最经常的模式，帮助团队的成员解决具体的问题，但是又不是代替成员去决策。
代理授权delegation：对于团队有经验的成员，能够对某个模块、系统、方向承担起相应的职责，我们尽量将职责代理给能够承担的同学。代理是把一件事情或者一个方向的决策权交给这个同学。有同学可以被授权负责某些方向是团队逐渐成熟的很重要标志。
达成共识consensus：当前的问题，需要经过引导/讨论/脑爆的模式形成共识，可以设计合理的会议流程和话题引导，给大家充分表达的机会，形成共识，促进更好的协同行动。
直接下达命令directing：总会有一些场景，因为时间紧迫，没有时间讨论形成共识，那么就明确告诉团队决策，大家按照决策执行。但是不管什么情况，管理者不能带给团队一个不敢反馈的氛围，如果因为自己的管理风格问题导致听不到声音是最危险的。
具体的细节有很多管理/领导力的书籍可以参考，这里不展开，关键在于我们要了解这些模式并有意识的选择和应用。
了解自己
一线的主管是两个不同职业的交界点：（1）（资深）研发的工程师；（2）人员管理者。但是这不是一个在工程师路线上的晋升，而是一次偏离，当然这个偏离不是不归路，最终如果自己不喜欢，经过一段尝试也可以回来，毕竟不是所有人都适合或者喜欢管理的角色。
工程师面对的是代码和需求。管理者面对的是团队，是人。在自己转换为一线主管后，可以两个角色都承担，各自分一部分时间，但是这也是逐渐脱离研发工作的过程。而且这个过程中，你所脱离的，是自己非常擅长的技术工作（否则一般也不会有机会成为主管），而正在适应的，则是一个需要全新的技能、自己还是一个新手、还会犯很多错误的岗位。
这不是一次晋升。你还是你，一顶新的帽子并没有意味着你有更大的权威。工程师只会真心佩服专业度，而不是一顶帽子，或许因为打绩效的关系，他们不得不听从你，但是这绝非对你个人的服从，而是对公司制度的遵从。
管理者确实带来了更大的掌控力，可以带领更多的人做事，但是要意识到，带领一个团队所做的东西，并不等于个人的成果。对团队带来多大的帮助，带来什么增量，才是真正的价值。而且如果这个管理者心中怀有的想法是把团队的成果作为自己的credit，我非常怀疑这样的人能够成为一个成就他人、给公司带来真正价值的主管。
但是也必须承认，今天在绝大多数科技公司，技术路线的上升通道都比不上管理路线的上升通道（注意，上升通道指的是在公司内职位晋升，并非个人技能的提升），这是一个现实，也是很多同学考虑转型管理路线的原因。
无路如何，这是一个职业生涯的转型，需要清晰地思考自己的规划并决定如何去选择。
所有的事情都需要学习，做研发团队管理者也不例外。研发的事情，我们是经过了多年的训练才达到今天的程度。管理者绝非是参加一次两次培训就能学会的技能，就像我们不会认为参加过几个小时培训的人就能符合工程师的要求。
如果我们问一个软件工程师，你学习过哪些软件工程相关的经典的著作，优秀的工程师可能会告诉你在过去N年里每年都在学习不同的知识。如果我们问一个管理者，针对管理你学习过什么专业的知识？读过哪本经典著作吗？估计情况就不那么乐观了。
既然承担管理者的角色，就要积极主动的学习。管理高科技公司的工程师责任重大，绝对不要因为自己手头的权力大、因为同学们都被要求“皮实、自省”而导致管理者从无知走到自大。（正文完）
附：招聘小贴士
阿里巴巴CTO线技术风险与效能部，欢迎关注大规模CPU和AI集群管理、研发运维体验，对K8s、Docker、Bazel、大规模持续集成和自动化测试平台、大规模代码平台、Linux内核等技术感兴趣的同学联系加入，有意者可联系liping.z@alibaba-inc.com
延伸阅读
1. Grow model for coaching and mentoring https://www.mindtools.com/pages/article/newLDR_89.htm
2. The five keys to a successful Google team: https://rework.withgoogle.com/blog/five-keys-to-a-successful-google-team/
3. RSA what motivates us: https://www.youtube.com/watch?v=u6XAPnuFjJc